gyaanipediafandomcom-20200213-history
Draft:Wagile (smart PMO, transformation delivery)
---- Wagile is a generic framework for the delivery of projects, programs, transformations (business, IT or digital) and entire project portfolios. The objective is to monitor and actively steer the delivery. The focus of Wagile is on educated decision-making and transparency. Wagile enables the parallel use of the waterfall model and agile methodologies. . Wagile is a registered trademark in EU , US and Switzerland . 'Motivation for Wagile' There are many instruments for the implementation of an IT & Project Governance, like SAFe, COBIT, CMM, PMBOK, TOGAF, and many others. Experience shows, that the selection, adaptation and introduction of suitable methods, processes and delivery organizations is a company individual process, that must consider the company's business model, structure, competences and, in particular, the corporate culture . The success factor for the implementation of an efficient IT Governance and a strategically aligned IT project roadmap, is the interaction of all IT governance domains, not the focus on one single domain only . The IT Governance domains are “Value Delivery”, “Risk Management”, “Resource Management”, “Performance Management” and “Strategic Alignment” WAGILE is closing this gap by linking standards and market best practices and existing legacy processes, considering all 5 IT Governance domains. 'Wagile Principles' Wagile is built on five basic principles: 1. Split decision research and decision-making 2. Formalize a decision process 3. Establish end-to-end accountability 4. Empower the delivery teams 5. Normalize and measure project indicators 1st Principle – split decision research and decision-making Objective: * Get transparency about solution scenarios and their impact on the delivery mandate and the business strategy * Take actively educated risks and decisions Splitting decision research and decision-making means separating the analysis about solution scenarios from the decision to the final solution. Decision makers do not have an active role in the decision research, decision research is the responsibility of subject-matter experts. Experts are risk averse and tend to think in silos. They naturally avoid proposing solution scenarios with residual risks. Decision makers can accelerate the decision research process by defining limiting mandates to experts, e.g. by excluding solution scenarios, by limiting the available time or the available budget. The results of the decision research are feasible solution scenarios with statements about their impact on the delivery mandate and risk assessments. In case decision makers consider the residual risk as critical, they can request additional risk mitigation actions on selected topics. A transparent decision research enables an organization to actively identify and take educated risks. It accelerates the decision process with a positive impact on the overall Time-to-Market. 2nd Principle – formalize a decision process Objective: * Implement a standard and transparent decision process * Accelerate and scale decision-making Key factors for a successful project delivery are engaged executive sponsors, their availability and the capability of fast and transparent decision-making. A precondition for a fast decision-making is the existence of a possibility to adapt decisions. The context for decisions might change during the lifecycle of a project. Decision makers are more willing to accept risks when having a possibility to adapt decisions if necessary. Wagile delivers strategies to reduce the dependency on availability and engagement of the executive sponsors by introducing decision gates and expert boards. The decision process itself is iterative, providing a possibility to adapt original decisions. * Expert boards provide alternative solutions scenarios, expert recommendations and risk assessments. Experts are not empowered to make decisions. Expert Boards have an [[End-to-end principle|'E2E']] responsibility for the technical and functional feasibility and the reliability of solution scenarios, including cost estimations and resource allocation. *Decision gates consist of empowered and legitimated decision makers who represent project sponsors and impacted organisational units. Members of the decision gate have an E2E accountability, including the strategic fit of recommended solutions. It is not a “discussion meeting”. Members of the decision gate must be prepared and informed, they send deputies in case of absence. Decision makers are expected to make decisions based on solution scenarios provided by the expert boards. Basis for this approach is the phased-gate process. The setup of expert boards and decision gates must be transparent and understood by the entire company and delivery organization. 3rd Principle – Establish end-to-end accountability Objective: * Avoid silo thinking * Avoid accountability gaps in the end-to-end delivery Most project organizations are organized as matrix organizations, influenced by the existing line organization. The objective of Wagile is to identify and avoid gaps in the end-to-end (E2E) accountability. Wagile distinguishes two types of E2E accountabilities: the vertical and the horizontal E2E accountability. '''''Vertical E2E accountability Vertical E2E accountability means the accountability to secure the integrity of critical business processes or the delivery of (new) products from an E2E perspective. Critical business processes are company-specific. For example, for a logistic oriented company these are “fulfilment” and “life of an order”, for a technical delivery this is a “sustainable and stable infrastructure”. The role of the vertical E2E accountability is typically taken by a line manager, a technical expert or a project manager. In vertical E2E accountabilities there is a low cross-functional impact. The responsibilities of “who does what” are naturally defined, owners of such accountabilities are found within the business lines. Horizontal E2E accountability Horizontal E2E accountability means the accountability to secure critical cross-functional delivery artefacts. Typical examples are “data quality management”, “closing process” or “business transition”. Examples for more technical delivery artefacts are “system performance / scalability”, “system security” or “operational readiness”. The role of a horizontal E2E accountability typically includes the alignment with all cross-functional stakeholders and shared services, like test management, release management, customer communication, and others. It also includes the alignment with the vertical E2E accountabilities. It is more difficult to find owners for horizontal E2E accountabilities, as there is no sponsor in the line organization. Without this role, the project manager is per default the horizontal E2E accountable for all those topics. 4th Principle – Empower the delivery teams Objective: * Empower delivery teams within a well-defined frame * Introduce awareness for the individual impact on the overall productivity Delivery units like project managers, development teams, a CIO and others, can only assume their entire delivery accountability when they are empowered to make decisions in their domain of expertise. The delivery organization must trust their expertise, experience, methodologies and best practices. Wagile considers empowerment as a key success factor for project delivery efficiency. Without empowerment, important decisions might get delayed and best practices, methodologies or the use of tools might get challenged by people who are neither experts in this domain nor do they have any delivery responsibility. Typically, the management of such interruptions is not estimated in the initial project scope, thus represents additional unplanned effort with risks to fulfill the delivery mandate. Empowerment also needs a well-defined frame to optimize delivery efficiency and to avoid conflicts and confusion. The frame gives direction and guidance for autonomous work. Good examples are the upfront alignment of performance measurements, like a velocity report. It should be closely linked to the overall company culture with regards to values, tools, processes and best practices. Wagile introduces the concept of pragmatic accountability. Its objective is to create awareness of the value of time and consciousness of one's personal impact on the productivity of others. The concept puts a frame around collaboration, communication and team work with the objective to reduce the risk of workforce unproductivity. The concept has mainly three aspects: 1. Awareness – being aware about one’s personal (un-)productivity and impact on the (un-)productivity of others, for example participation in meetings. 2. Risk consciousness – acting in a risk-driven manner, meaning one’s personal commitments and decisions are based on assumptions and risk assessments which are transparently shared with the team. 3. Respect – respecting the empowerment and the authority frame, trusting in expert knowledge and keeping own delivery commitments. 5th Principle – Normalize and measure project indicators Objective: * Create transparency about delivery efficiency * Generate traceable and factual statistics to facilitate discussions with business executives and stakeholders * Make projects comparable Wagile normalizes project execution monitoring by introducing common [[Key Performance Indicator|'Key Performance Indicators' (KPIs)]] for all types of projects. These KPIs are used as benchmark, e.g. the Time-to-market (TTM). A deviation to this benchmark is a valuable indicator of the project performance and allows comparison between different projects. It sets realistic management expectations to project stakeholders and delivery teams. Measuring the delivery performance creates transparency about the delivery efficiency and generates traceable and factual statistics to facilitate discussions with business executives and delivery teams alike. Without regular measurements, project-related decisions are taken blindly, the dialogue with stakeholders stays emotional. The establishment and the debriefing of an agreed KPI catalogue is a key item for the stakeholder communication. 'The Wagile standard model' The Wagile standard model supports the entire delivery Livecycle, from Idea-To-Request, Request-To-Requirement, Requirement-To-Offer, Offer-To-Acceptance, Acceptance-To-Rollout and Operation-To-Decommissioning, with four Wagile concepts: 1. Concept of ROADMAPiSATION 2. R@CE – Wagile Decision Concept 3. Concept of Commercial Seasons 4. ADIO – Product Management Concept It is possible to use each concept independently. ROADMAPiSATION (Stategic Development) The concept of ROADMAPiSATION facilitates the company-wide alignment of capital expenditures (CAPEX) and project selection / prioritization by introducing a pragmatic formalism and a healthy competition for limited resources. The Roadmap Entry Meeting (REM) The REM is the decision gate in the ROADMAPiSATION model. * It is formalising the process of selecting investment candidates by respecting the global financial boundaries. An idea with significant impact on human capital or budget must pass the REM to get the budget assigned and to be approved for the company roadmap. * Business usually has more ideas than IT has resources, the REM is therefore mostly a tough negotiation between IT and business. Due to this nature, the roadmap definition is an iterative process which needs time and strong steering. Multiple REMs are usually necessary to define a roadmap. * The frequency of roadmap plannings should be low to avoid overhead to the entire organization. A healthy rhythm is twice a year (in Q4 to plan the following year, in Q2 to adapt for the current year). * Frequent changes to the roadmap have a negative impact on long term planning. Important delivery units like preferred partners (missing visibility / reduced trust), IT (missing key resources and skills) might not be able - or willing - to support frequent changes. Cross-functional project impact assessment (PIA) The PIA as the ROADMAPiSATION expert board, recommends feasible solution scenarios to the REM. Recommendations are aligned with the long-term strategy of each functional domain. * The PIA is assessing ideas with regards to process, system and organizational impacts. * Stakeholders from relevant business and technical domains send experts to this board. * The objective is to set realistic management expectations early in the project delivery lifecycle, to reduce the risk of approving bad apples to the company roadmap and to identify necessary technical enablers. * The PIA and the preparation for the PIA is per its nature a bottleneck with high competition for experts. Competition increases the motivation of stakeholders to actively participate in the ROADMAPiSATION process. ROADMAPiSATION prevents Shadow IT and avoids the underestimation of projects by formalizing the idea selection process and introducing healthy competition for the limited resources budget and human capital. A pre-condition for an efficient ROADMAPiSATION is the centralization of CAPEX budget. CAPEX should only be assigned via this process or via senior management exception. 'R@CE – Wagile Decision Concept' The Wagile Decision Concept “''R@CE''” stimulates anticipatory and educated decision-making by providing flexibility and adaptability in the frame of a formal decision process, imposing legitimation and accountability to decision-makers. R@CE is based on the phased-gate concept. The focus is to enable fast decision-making in a transparent, calm, systematic and pragmatic way, and to approve key project lifecycle milestones. The objective of R@CE is to reduce the dependency on individuals and to stimulate risk-driven educated decision-making. R@CE scales phased-gate models from a project centric to a roadmap holistic level and solves project delivery inefficiencies by introducing flexibility and risk-driven decision research. Decision Gates in R@CE Decision gates in R@CE act as the investment committee and are accountable for the realization of the company strategy. They take project lifecycle decisions, approve the project delivery strategy and set or change the project mandate. They confirm the allocation of resources to projects (like budget, human capital) and decide or change the priority of projects or deliverables · A decision gate takes the following decisions: “go” (proceed), “go with conditions”, “kill” (cancel), “hold“ (suspend), “No go“ (come back). · Each company must define decision criteria which consider financial and qualitative measures. In every gate meeting projects are challenged against these criteria. · The application of common and transparent gate transmission rules (to get a time slot) is necessary to avoid the risk of delayed decisions It is a significant effort for delivery teams to prepare and pass decision gates. Wagile therefore recommends a minimum of decision gates with regards to the principle of empowering delivering teams and the effort of preparing decisions. The gates are: G0 - GO for analysis G1 - GO for development optional G2 - GO for change G3 - GO for production Expert Boards in R@CE Expert Boards act as the expert committee and are responsible for project feasibility in alignment with company strategies. They assess the project impact considering regulatory, security and compliancy related requirements and propose a project delivery strategy, highlight assumptions and potential risks. They recommend solution scenarios, provide cost estimates, resource allocations with a realistic start date and analyze the impact to the overall project roadmap in case of resources conflicts, redundant activities or contradictory projects objectives. * An expert board makes these potential decisions: “go”, “conditional go”, “reject“ * Expert boards are no decision boards and can only give recommendations and risk assessments to the decision gate. Thus, an expert board can not stop a project of moving forward. Even if an expert board rejects certain solution scenarios, the decision gate still can accept the risk and potential impacts. * A frame is necessary to enforce efficiency in expert boards, e.g. the measurement of the quality of recommendations of expert boards. Iterations for decision gates For high risky or complex projects, the instrument of iteration (passing multiple times the same decision board) provides the opportunity for an accelerated decision process. Iterations offer to delivery teams a regular steer, create transparency and prevent conflicts. Iterations also reduce the resistance for decision-makers of decision-making, as there is a possibility of a later adaption. The frame of changing decisions must be aligned with the delivery teams as every change has impacts on resource allocation. R@CE and Agile delivery Proof of Concept (PoC) A PoC is the realization of a certain method, technology or idea in a pre-defined and realistic implementation context. The objective is to demonstrate feasibility, to validate assumptions, to set realistic management expectations very early in the project delivery lifecycle and to reduce the overall risk for underestimating complexity and approving bad apples to the company roadmap. A realistic and meaningful PoC in a software or infrastructure context needs budget and resources. It therefore has to be prioritized in the ROADMAPiSATION process. The PoC is an instrument to accelerate the delivery of complex projects by short cutting analysis and specification activities. It increases the delivery efficiency as it reduces risk and motivates both, internal employees and external suppliers, to participate in innovative activities or to prove functionality as an argument for a final solution. Agile delivery strategies Wagile recommends mainly two strategies for Agile delivery: Full Agile and Wagile. Full Agile Full Agile delivery strategies are applicable for existing Software solutions with no fundamental changes in the enterprise architecture, infrastructure or security models. The focus is on enhancing existing features or adding new features or new functionalities. The impacted delivery teams are typically not cross-functional, only one team is responsible for the delivery. Wagile Wagile delivery strategies are applicable for major transformations, complex projects or projects with a fix delivery timeline (e.g. regulatory requirements). One possibility to use Wagile is to split a big project scope into Agile components like the Software development, and Waterfall components like the purchase and set-up of Infrastructure. Another possibility to use Wagile is to invest more time in formalizing the implementation strategy and analyzing the “big picture” in terms of functionality and E2E process before immediately starting Agile developments. E2E analysis and conceptual work can be planned upfront each Agile increment. This approach ensures functional, organizational, processual and technical integrity for every Agile delivery cycle. In such a scenario, senior management can measure the overall completion rate of Agile deliveries, as there is a measurable scope reference defined. In such an approach, not only the performance of delivery team gets measured, but also the completion rate of the project mandate. Concept of Commercial Seasons (CS) The concept of commercial seasons provides one common company-wide delivery process with a cross-functional vocabulary by standardizing and time-scaling business and technical related activities. The focus is to facilitate product innovation while considering existing delivery dependencies, to set realistic management expectations for market launch and to define measurable targets for the delivery organisation. The objective is to combine Go-to-Market activities (e.g. in marketing, sales and customer care like the timely creation of publicities, user training, customer communication) with IT activities (e.g. Release Management, Production deployment) to achieve economies of scale, to standardize repeating activities and to align go-to market and communication with technical rollout planning. The concept introduces strict company-wide rollout dates while staying open for change. Wagile recommends managing a commercial season as a horizontal responsibility and to name one responsible CS owner to align important milestones (e.g. launch date for customer communication) between the different organizational units and the delivery teams. The Operational Review Board (ORB) is an instrument from ITIL. The ORB holds the service acceptance review meeting representing the final acceptance gate. The validation is done against the acceptance criteria checklist to ensure that the service promise to the business will be kept. Once all acceptance criteria are met, the new or modified services are ready for launch with the Commercial Seasons. The G4 decision gate is used for the project delivery performance review. It is the formal closing of a project. Closing a project means to formally handover the maintenance, monitoring and operations to the respective organizational units and to fully release the project teams and the project manager. Typical activities in the project review are: * Review project delivery vs. project mandate * Review results of the market launch * Acknowledge lessons learned and approve corrective actions * Decide if the Product / Service is managed in In Life Management * Close the project ADIO Product management (Customer Development) Product management is understood as an holistic service, supporting customers making the right decisions and actively drive the product roadmap rather than reacting on competition or bad performance. ADIO = A'NALYSE – '''D'EFINE – 'I'MPLEMENT – 'O'RGANISE ADIO is an holistic approach consisting in: * ANALYSE – a constant analysis of cost, performance, processes, systems, vision, customer satisfaction, customer needs, market development, competition, sales approach, distribution channels, commissioning, innovations, positioning or the P&L is key to improve the current product, to come up with new products and to be ahead of the game. This process ensures new ideas to enter the roadmap. Worst case, a new project for product decommissioning / pruning is initiated – and even this must be carefully delivered, especially if there are still customers using it. * DEFINE the plan: having a vision and a plan is important to align the overall organization with its own ambitions. This creates visibility and ensures faster delivery due to a clear understanding. * IMPLEMENT clean products solving upcoming challenges and resistance, be flexible with the implementation and ensure best communication. Be as simple as possible: Simplicity is the key to success. It is highly recommended to get challenged in simplicity and to simplify in iterations. * ORGANISE the correct set up for a product delivery with a real E2E accountability and responsibility. Challenge the status quo and the way things are organized today. Keep in mind, the stakeholder providing business requirements and inputs are very often not willing to change too much and to “protect” their current scope. ADIO Product Management is driven by the constant motivation to challenge the status quo and to improve the current situation. The new ideas are coming up or the circumstances around the product / offer are changing and could be the reason for the change and a new project or release. '''Wagile Monitoring Model The Wagile monitoring model defines standard decision governance milestones and key performance indicators valid for all projects and initiatives on the project roadmap. The focus is to monitor the project roadmap execution and the project delivery performance without adding additional bureaucratic constraints or tools to the operational teams. The objective is to enable anticipatory management strategies versus reactive decision strategies. The Wagile governance model enables roadmap execution and project performance monitoring. It allows a constant optimization, learning and improvement to achieve more efficiency in the project delivery process. Wagile elevator speech Wagile supports existing delivery processes and tools. Wagile is able to integrate a combination of planning elements from Waterfall and Agile methodologies alike – “WAGILE”. The focus in Wagile is on transparency and on the management of external project factors like the availability and legitimation of decision-makers. The objective of Wagile is to centralize the delivery of change and to industrialize decision-making. Global transparency and delivery execution monitoring is a natural consequence. Wagile is a framework that can be applied on project, program or portfolio level. References